With the development of communication technologies, how to guarantee a quality of data transmission and how to rapidly locate a failure when a failure occurs on data transmission has become a problem urgent to be solved. Therefore, BFD, as a fast detection mechanism, emerges as the times require. In BFD, a link is detected by a rapid “Hello” mechanism with a rate that can be negotiated.
BFD may be used for detecting the correctness of various types of transmission, including Ethernet, Multi-Protocol Label Switching (MPLS) Path, common routing encapsulation and IP network security protocol (IPSec) tunnel.
BFD is developed from the basic transmission technology step by step, so with BFD, failure in each layer of a network may be detected. The object of BFD is to provide a failure detection mechanism with a low overhead and a short detection period on a path between adjacent routers. The adjacent routers refer to routers connected via any one or more logic links, and it is not limited to one hop between the routers. BFD may perform detection on an interface, a data link and even extended to a forwarding engine itself.
FIG. 1 is a schematic diagram showing networking of an overall application environment of BFD. In the networking, router A, router B, and router C are all implemented with BFD function. Router A and router C are connected via a link AC, router B and router C are connected via a link BC. BFD may be applied on links AC and BC for detecting failure status of the links.
BFD may be abstracted as a simple service, and service primitives provided include: creating, deleting and modifying a BFD session under the premise of a given destination address and other parameters. In BFD, a signal is provided to an operator to indicate the start or end of a BFD session, or to inform the operator of the BFD session negotiation result or the modification result, etc., and to provide state information of a detected link to the application layer, for example, information UP indicates that the link is in normal state, while DOWN information indicates a link failure.
BFD is similar to “Hello” protocol. After a BFD session is established, the two parties of the BFD session periodically send BFD packets to the opposite party on a link on which BFD is applied, and periodically detect arrival status of packets from the opposite party on the link. If a party does not receive a BFD packet from the opposite side within a time interval, it is regarded that a failure occurs on the link, so as to rapidly find a link failure.
In the networking shown in FIG. 1, it is assumed that router A and router C are mutual neighbors in a BFD session, and no BFD session is established on the link AC initially. The lifecycle of a BFD session mainly has the following stages:
1) Initial Establishment of a BFD Session.
Firstly, a BFD instance is created on router A and router C respectively. Then, router A and router C obtain IP addresses of their neighbors. BFD has no automatic neighbor finding mechanism, so a BFD instance may obtain the IP address of a neighbor via static configuration or depending on other application protocols.
After obtaining the IP address of a neighbor, the BFD instance obtains a discriminator assigned by the opposite party and assigns a discriminator locally. The discriminator may be configured manually, or obtained via automatic in-band negotiation or out-band negotiation. In other words, negotiation of the discriminator is performed via another application protocol and then notified to the BFD instance. If the automatic in-band negotiation mode is employed, the timing sequence of the BFD session is established between routers via three handshakes, the specific negotiation of which is irrelative to the invention, and reference may be made to related BFD protocol documents.
2) Parameter Negotiation of a BFD Session.
After a BFD session is established between BFD instances of the neighbors via three handshakes, BFD session parameters need to be negotiated to conform the BFD packet transceiving speed, failure determination time and session mode (such as asynchronous mode or synchronous mode) of the two parties.
Before starting the BFD session parameter negotiation, each router estimates its capability of sending and receiving BFD packets based on preset conditions, such as influence on bandwidth and CPU occupancy. Then it negotiates the shortest time to detect a failure, i.e. failure determination time, with a neighboring router. The failure determination time negotiated may be modified in real time.
Once various BFD session parameters are negotiated and the BFD session is established, the BFD session is triggered into a failure detection stage.
3) BFD Failure Detection.
In the invention, BFD failure detection stage is illustrated in the case that BFD session mode is asynchronous mode. After the BFD session is established and related parameters are negotiated, the parties of the BFD session periodically send a BFD control packet to the opposite side according to asynchronous mode in a time interval that is negotiated. The BFD control packet is adapted to perform heartbeat detection. The function and operation mode of the BFD control packet is the same as that of a HELLO packet of other routing protocols but the sending frequency is usually higher.
When one party of the BFD session sends the BFD control packet to the opposite side, it periodically detects the BFD packet sent by the opposite side. If it detects that a preset number of BFD packets from the neighbor are lost consecutively, it declares that failure occurs on the link and informs other applications, such as routing modules, of a link failure message. The number of BFD packets lost consecutively when it is declared that failure occurs on the link is determined according to the BFD session negotiation result, and this parameter is defined in the BFD control packet format via a Detect Mult field.
In BFD draft, no protocol for bearing BFD packets is specified; instead, it only proposes to encapsulate a BFD packet by using User Datagram Protocol (UDP), and the BFD packet is identified by employing a UDP destination port number 3784. The format of a BFD packet encapsulated in UDP is as shown in Table 1:
TABLE 10123456789012345678901234567890 1VersDiagStaPFCADRDetect MultLengthDiscriminator generated by the sending system (My Discriminator)Discriminator received from the corresponding remote system (Your Discriminator)Minimum BFD control packet sending interval desired by the local system (Desired Min TXInterval)Minimum BFD receiving interval supported by the system (Required Min RX Interval)Minimum interval of received BFD echo packet supported by the system (Required Min EchoRX Interval)The following authentication data is optionalAuthenticationAuthentication LengthAuthentication DataType (AuthType)(AuthLen)(AuthenticationData)
The meaning of each field of the BFD packet in Table 1 is shown in Table 2:
TABLE 2Domain NameMeaningVersion (Vers)BFD Protocol Version Number, the current version number is 1Diagnostic (Diag)Diagnostic Code describes the causes the local system turns to otherstates from Up state last time. The meaning is as follows:0 represents No Diagnostic1 represents Control Detection Time Expired2 represents Echo Function Failed3 represents Neighbor Signaled Session Down4 represents Forwarding Plane Reset5 represents PathDown6 represents Concatenated Path Down7 represents Administratively Down8-31 represents Reserved for future usestate (Sta)“State” represents the current BFD session state as seen by thetransmitting system.Values are:0 represents Administrator set session DOWN(AdminDown)1 represents BFD session state is DOWN (Down)2 represents an initial state (Init)3 represents BFD session state is UP (UP)Poll (P)If set as 1, it indicates that connectivity needs to be verified or parametervariation required; if it is set as 0, no verification is needed.Final (F)1: For a BFD packet received, if Poll is set, respond to Poll;0: Not respond to Poll.Control Plane1: BFD only runs on the data plane, and it is not influenced even if theIndependent (C)control plane collapses;0: BFD application shares the state of the control plane (In other words,it collapses when the control plane collapses).Authentication1: Session needs to be authenticated.Present (A)Demand (D)When set as 1, it indicates that the system expects to operate in demandmode; otherwise, the system does not expect to or cannot operate in theabove modeReserved (R)They must be all zero, and the receiving party ignores these bits.Detect MultDetect time multiplier: when transmission interval is negotiated, it needsto be multiplied by this value. This value is used in asynchronous mode.In asynchronous mode, Detect_Mult requires the detection period of theopposite party; in Demand mode, Detect_Mult notifies the oppositeparty of its own detection period.LengthLength of a BFD control packet in units of byte.My DiscriminatorIt is a unique nonzero discriminator between two systems generated bythe sending system, and used for the demultiplexing (identification) ofmultiple BFD connects.Your DiscriminatorDiscriminator (value) is received from the corresponding remote system,and this field is sent back from the received My Discriminator. They arefilled as all zero if the situation of the opposite side is unknown.Desired Min TXMinimum BFD control packet sending interval desired by the localIntervalsystem, in units of microsecond.Required Min RXMinimum BFD sending interval supported by the system, in units ofIntervalmicrosecond.Required Min Echo RXMinimum interval of received BFD echo packet supported by theIntervalsystem, in units of microsecond. If it is set as 0, the transmitting systemdoes not support BFD echo packet.Auth TypeIf A is set, the field represents the authentication type. The meaning is asfollowing:0 represents Reserved (Reserved)1 represents Simple Password Authentication (Simple Password)2 represents Keyed MD5 Authentication (Keyed MD5)3 represents Meticulous Keyed MD5 Authentication (Meticulous KeyedMD5)4-255 represents Reserved for future useAuth LenLength of the authentication part in units of byte, including Auth Typeand Auth Len
In asynchronous mode, because BFD needs to send and detect a BFD packet rapidly, the sending and detecting of the BFD packet are both performed via logically simple hardware, which is usually configured on a forwarding plane. The establishment and negotiation process of a complex BFD session should be accomplished by software or universal hardware with more complex logic, etc.
In this disclosure, an establishment and negotiation module of a BFD session is abbreviated as a negotiation module, and a sending and detection module of a BFD packet is abbreviated as a detection module.
In the prior art, a method for performing failure detection on a BFD session is as follows:
After a BFD session is established and various BFD session parameters are negotiated, the various BFD session parameters negotiated, such as sending interval and detection interval, are notified to a detection module. Upon receiving the parameter information, the detection module starts a sending timer immediately and periodically sends BFD packets to the opposite side, and at the same time, a timer for detection timing is started immediately and the arrival status of the BFD packet from the opposite party is detected. According to the parameter information negotiated, if it detects that a predetermined number of BFD packets from the opposite party are lost consecutively, it declares that failure occurs on the link. FIG. 2 is a schematic diagram showing a failure detection timing sequence of a BFD session in the prior art. As shown in FIG. 2, provided that, according to the negotiated result of the parameter negotiation stage, router A sends a BFD packet in a time interval of 10 ms as shown by the bidirectional dash-and-dot line in FIG. 2, and router B sends a BFD packet in a time interval of 15 ms as shown by the bidirectional dashed line in FIG. 2. If router A detects that 3 BFD packets sent from router B are lost consecutively, i.e. when lost count is 3, router A declares that failure occurs on the link and sends a state information of the link detected as information DOWN to the application layer.
The above method for detecting the transmitting of a BFD packet has the following disadvantages: in practical applications, the negotiation module needs to spend a time period in notifying the detection module of the parameter negotiation result, the length of the time period is usually influenced by many factors. One of the factors is the busyness state of the negotiation module. Because the negotiation module usually bears tasks of many other BFD sessions, such as establishing, negotiating and routing, the negotiation module is usually very busy. Another factor is the congestion state of the channel between the negotiation module and the detection module. Therefore, the delay needed by the negotiation module to deliver the BFD parameter to the detection module is unpredictable. Sometimes it may be very long, and sometimes it may be very short. Especially when a performance difference or load difference exists between the neighbors of a BFD session, the delay difference is more apparent. When the delay reaches a value, it is inevitable that one side of the BFD session misinforms that a failure occurs on the link.
FIG. 3 is a schematic diagram showing that one side of a BFD session misinforms that a failure occurs on the link. As shown in FIG. 3, in the detection process, router A sends a BFD packet in a time interval of 10 ms as shown by the bidirectional dash-and-dot line in FIG. 3 according to the BFD session negotiation result of the negotiation stage, and router B sends a BFD packet in a time interval of 15 ms as shown by the bidirectional dashed line in FIG. 3. However, due to various causes, router B cannot deliver the BFD session parameter to the detection module in a long time. After router A detects that 3 BFD packets sent from router B are lost consecutively, in other words, when lost count is 3, router A declares that failure occurs on the link and sends the state information of a link detected as information DOWN to the application layer. In FIG. 3, the time when the negotiation stage of the two parties ends is T0, the time consumption for delivering the BFD session parameter to the detection module by the negotiation module of router A is Ta as shown by the heavy bidirectional dashed line, and the time consumption for delivering the BFD session parameter to the detection module by the negotiation module of router B is Tb as shown by the bidirectional double dash-and-dot line.
It can be seen from FIG. 3 that, if Tb is larger than the sum of Ta and the 45 ms detection time of router A, router A misinforms that a failure occurs on the link. Here, because it is detected that 3 BFD packets are lost consecutively and the sending time of each BFD packet is 15 ms, the detection time is 45 ms.
In view of the current method for failure detection on bidirectional forwarding, after various BFD session parameters are negotiated and a BFD session is established, the two parties of the BFD session are triggered into a failure detection stage. Because a difference exists between delays needed by the negotiation modules in routers of the two parties of the BFD session to deliver BFD session parameters to the detection module, the router may misinform that failure occurs on the link during failure detection.